@anton-seaice, it looks like 'mosaic' in this context has nothing to do with the field campaign. Is that correct? If so, it could be confusing for other users interested in the MOSAiC data. Let's figure out how to document both to reduce confusion. Certainly explain what they are in the readthedocs, but also perhaps add some comments to the diagnostic output?

@anton-seaice, it looks like 'mosaic' in this context has nothing to do with the field campaign. Is that correct? If so, it could be confusing for other users interested in the MOSAiC data. Let's figure out how to document both to reduce confusion. Certainly explain what they are in the readthedocs, but also perhaps add some comments to the diagnostic output?

I agree. Maybe mosaic is not the right term to use here. Maybe mom_supergrid or just 'mom'. Also, I would add that grid_type has the following options currently: 'displaced_pole', 'tripole', 'default', 'regional', and 'latlon'. So, perhaps we should do something like 'mom_tripole'?

Thanks both

Yes definitely unrelated to MOSAiC voyages.

The term mosaic and supergrid are used a little bit interchangeably, although most of the MOM6 source code and the ESMF docs refer to a mosaic specification, so I used that. Happy to change to calling it supergrid if that is clearer. I didn't want to only refer to it as the MOM format because there are is an earlier mom format which is different.

@dabail10 - apologies - there was an error in the description, which i've just amended. This changes adds grid_format = mom_mosaic and it supports the existing grid_type options of regional, tripole and displaced_pole. The only one it doesn't support is tripoleT and aborts if that configuration is set.

Thanks both

Yes definitely unrelated to MOSAiC voyages.

The term mosaic and supergrid are used a little bit interchangeably, although most of the MOM6 source code and the ESMF docs refer to a mosaic specification, so I used that. Happy to change to calling it supergrid if that is clearer. I didn't want to only refer to it as the MOM format because there are is an earlier mom format which is different.

@dabail10 - apologies - there was an error in the description, which i've just amended. This changes adds grid_format = mom_mosaic and it supports the existing grid_type options of regional, tripole and displaced_pole. The only one it doesn't support is tripoleT and aborts if that configuration is set.

I understand now. However isn't grid format either nc or bin? Maybe this should be mom_nc?

I understand now. However isn't grid format either nc or bin? Maybe this should be mom_nc?

I figured there would never be a mom_mosaic grid not in a netcdf format, so i didn't think we needed to included nc.

If it is clearer we could use mom_nc or leave grid_type alone and add a new namelist variable (e.g. grid_specification and it could be type pop or mom_mosaic)

I understand now. However isn't grid format either nc or bin? Maybe this should be mom_nc?

I figured there would never be a mom_mosaic grid not in a netcdf format, so i didn't think we needed to included nc.

If it is clearer we could use mom_nc or leave grid_type alone and add a new namelist variable (e.g. grid_specification and it could be type pop or mom_mosaic)

This might be better. However, I think this is overkill. I think grid_format = 'pop_nc' or 'mom_nc' is fine. I also really think you should not have "mosaic" in the name. This is going to be confusing.

This might be better. However, I think this is overkill. I think grid_format = 'pop_nc' or 'mom_nc' is fine. I also really think you should not have "mosaic" in the name. This is going to be confusing.

I guess if we just cover that a mom_grid refers to a mom mosaic / supergrid format in the docs then its sufficiently clear that is the format being referred to ? Its unlikely that configs using the latest CICE will want to use an old MOM grid format ?

I understand now. However isn't grid format either nc or bin? Maybe this should be mom_nc?

I figured there would never be a mom_mosaic grid not in a netcdf format, so i didn't think we needed to included nc.
If it is clearer we could use mom_nc or leave grid_type alone and add a new namelist variable (e.g. grid_specification and it could be type pop or mom_mosaic)

This might be better. However, I think this is overkill. I think grid_format = 'pop_nc' or 'mom_nc' is fine. I also really think you should not have "mosaic" in the name. This is going to be confusing.

Before I get more into this, I am so grateful that you've done the work on this!

I just talked to one of our MOM6 developers here. Here is what I think we should do:

For POP binary and netcdf files: grid_format = 'bin','nc' , kmt_type = 'file'. This maintains backward compatibility.

For MOM6 supergrid files: grid_format = 'mom6_nc' and kmt_type = 'none'. Then key off grid_format to see if we need to read in the MOM6 bathymetry file.

The "mosaic" file was an older MOM file. We will never have to support this. Our MOM developer has a script called mosaic_to_supergrid.py. I agree that we should stop using 'kmt' but again for backward compatibility, I think we leave it as kmt for now.

Hopefully it saves us generating many CICE grid files offline :)

Ok great - those namelist options are ok with me.

I haven't tried loading a bathymetry file yet, is the format of the CICE bathymetry file different to the MOM6 format ?

I was planning to, in a later PR, generate the CICE land/sea mask from the bathymetry file. In the interim, we would keep using the current kmt_type=file for the land/sea mask - is that consistent with your thinking ?

Hopefully it saves us generating many CICE grid files offline :)

Ok great - those namelist options are ok with me.

I haven't tried loading a bathymetry file yet, is the format of the CICE bathymetry file different to the MOM6 format ?

I was planning to, in a later PR, generate the CICE land/sea mask from the bathymetry file. In the interim, we would keep using the current kmt_type=file for the land/sea mask - is that consistent with your thinking ?

I think the MOM6 bathymetry is very different from the one CICE expects. So we will also have to use grid_format here. I definitely agree with keeping kmt_file around for the near future.

For POP binary and netcdf files: grid_format = 'bin','nc' , kmt_type = 'file'. This maintains backward compatibility.

For MOM6 supergrid files: grid_format = 'mom6_nc' and kmt_type = 'none'. Then key off grid_format to see if we need to read in the MOM6 bathymetry file.

@apcraig - are these option names ok ? implementing the MOM6 bathymetry would be a future PR

I think the current plan is fine. We should maintain the current namelist and backwards compatibility whenever possible. I also agree that using "mosaic" could be confusing.

Would having a kmt_type='grid' make sense? That would mean the kmt info is on the grid file? Or maybe even kmt_type='grid' and kmt_type='grid_bathy'. The former means the mask is read off the grid file, the latter means the bathymetry is read off the grid file then a kmt mask is created. And how does that interact with the bathymetry namelist values? I haven't looked at all the current and possible permutations of grid/kmt/bathy options, but maybe we should clarify all the existing and potential options and make sure we have a clear set of namelist values that make implementation of them clear (without breaking backwards compatibility).

Thanks - I change mom_mosaic to mom_nc and updated the comments / names etc as needed